ALIM Web Implementation Guide

<blocktasks> Configuration

Tasks to be blocked are defined in an xml configuration file. This file is located in the ObjectActionManagement plugin subdirectory of the ALIM Web virtual directory. As previously described in Configuration, a separate configuration file is defined for each ALIM Web Community, accessible from a virtual directory. Thus, a specific task such as Add Note, can be blocked on "Community A", yet allowed on "Community B". Two separate virtual directories, "Novice" and "Expert", both with access to the same ALIM Web Community can also be configured, each with its own set of blocked and/or added tasks. For example, the "Novice" virtual directory can block many of the ALIM Web standard tasks such as Add Note, Add to Basket, Add to Folder, Explore from Here, and others, providing a limited set of tasks for the beginner.

Tasks are blocked by specifying the object Type and the Object Class Code of the object displayed in the Content Pane. The Object Type value is a number, for example, Document = "3", Event = "94", and Item = "1". If a specific Class Code is supplied, you can further specify whether or not all Child Classes are to be included.

Tip: You can use the asterisk (*) wild card in the Object Class Code to specify all classes of an object or a specific Class Code.
Note: Some plugins are dynamic, meaning that the same Task ID may be applicable to multiple related object instances. For example, a work order with multiple work steps may have a task that could pertain to each work step in the workflow. To accommodate this, a plugin may dynamically generate the Task ID, by appending a numeric value to the Task ID Name. Thus, a task named "wcAccept" would have a Task of "wcAccept_nnnnn", where "nnnnn" represents a numeric value with no leading zeros, for example, wcAccept_1, wcAccept_2, and wcAccept_234. To block the wcAccept tasks, the Task ID specified in the configuration file is "wcAccept*".

Additionally, the configuration file contains a parameter <pluginswithwctasks> to indicate those plugins which may have dynamic Task IDs. This must be indicated for the plugin to properly handle the dynamic Task IDs for a specific plugin.

The <blocktasks> node manages the blocking of out-of-the-box tasks, for example:

<blocktasks>
   <pluginswithwctasks>wcTaskPlugin</pluginswithwctasks>
   <object type="94" classCode="*" blockchildclasses="true">
      <task>wcAccept*</task>
      <!-- <task>wcAcceptEdit*</task> -->
   </object>
	  <object type="3" classCode="*" blockchildclasses="true">
		   <task>dmNewRev</task>
		   <task>dmCheckOut</task>
		   <task>dmLock</task>
	  </object>
</blocktasks>

See Appendix - Task IDs for a complete list of Task IDs.

Some plugins have task names that are not constant. For example, a plugin may have dynamic task names such as wcAccept<workstepid>. If there are additional plugins that support wild card tasks such as this, leave the current node with the wc supported plugin as is, and then insert the additional plugins to the <pluginswithwctasks> parameter, separated by a vertical bar ( | ), for example:

<pluginswithwctasks>wcTaskPlugin|TestPluginID</pluginswithwctasks>

In the configuration file, there may be one or more <object> nodes specifying each of the Object Types. For example, object type="3" represents documents, and object type="94" represents events.

In the classCode=“ENG” object parameter above, the tasks will be blocked only for documents with class "ENG".

Tip: To block tasks for all class codes, use classCode=“*”.

The blockchildclasses=“true” attribute denotes that some configured tasks will be blocked for child classes.

Note: The <blockchildclasses> parameter is only applicable when the class code is not = "*".